2025 Status of Rust on Zephyr

Properties

Add property

There has been a lot of recent hype over the Rust Programming Language, and especially from a perspective of security, some desire to see an increase in the use of Rust in embedded systems.

The Zephyr RTOS has also seen a lot of activity recently.

It so happens, that I've spent the last 6 months working to make these work together. The most recently Zephyr Release explicitly states support for Rust. The question what can it do, and what is it useful for.

Std or not

There are a few ways to approach supporting Rust on an RTOS. Some previous efforts have focused on bringing support for Rust std library to the platform. This can definitely help with porting of applications and that type of effort.

However, this also comes with a cost. The std library is built around a few assumptions that aren't really true on most of the platforms that Zephyr is used on:

Std is build around fairly extensive use of alloc. On desktop and server type of machines, assuming that dynamic allocation is available is fairly pervasive, and many of the abstractions in the std library assume they are free to not just allocate, but allocate fairly freely. Embedded systems are often significantly memory constrained (Having tends of Kb of ram is common). Although using Rust addresses many of the concerns with using dynamic memory, there is still an overhead to using it, and I feel it would be much better to build support for Zephyr without this requirement. This aligns well with other projects with rust-embedded, including Embassy
Most of the rest of the support within std concerns either filesystem or networking support. Neither of these are commonly available on embedded targets. Where they are, support is usually constrained significantly over what would be typical applications (e.g., filesystems have to be used carefully, or networks have to carefully manage connections and things like certificates). For example, a typical desktop network application that connects to an HTTPS service will use a certificate database that is larger than the entire codespace available on many microcontrollers.

As such, this approach to support Rust on Zephyr has taken an approach closer to that done by the Rust Embedded project.

Core RTOS functionality

What an RTOS such as Zephyr provides can be broken down into a few categories:

Core support. In Zephyr, this is referred to as the kernel. This provides a set of abstractions that can be used to build applications:
- Threads: Zephyr is built around a thread-centric model of programming an RTOS (see below on Embassy and Async, though). A typical application will create several threads, which will be given fixed priorities.
- Communication primitives. The other main functionality will be primitives to allow these threads to communicate. In our case, we have focused on Semaphores, Mutexes and Condition Variables, and Message Queues, as well as spin locks.
- Memory management. Zephyr provides an optional allocation mechanism that provides something akin to malloc and free.
- Timers. Zephyr has a timer infrastructure to allow threads to wait for specified periods of time as well as to give timeouts to operations.
- Other support. The kernel in Zephyr (as well as some utility libraries) provide additional support for. Many of these provide utilities that are not available in the C language. Most of these have better solutions already available either in the Rust core library, or in one of the many crates. Binding to a utility written in C is likely to result in an inferior experience to just using native functionality in Rust.

Std or not

Core RTOS functionality

Alloc

Threads

Primitives

Timer

Embassy

Userspace